New CASB Survey Findings Point to Critical Requirements

Doug Cahill, Jon Oltsik, and Bill Lundell, cybersecurity researchers at Enterprise Strategy Group, published a new study last month on the Cloud Access Security Broker (CASB) market entitled “The Visibility and Control Requirements of Cloud Application Security.” Besides being a really telling piece pointing to the need for CASB across most enterprises, the study’s findings set the stage for five critical requirements for CASB technology.

The study relies on an in-depth survey of 302 IT and security professionals in North American enterprises above 1,000 employees and annual revenue greater than $50 million. Below are five findings and what they mean for enterprise CASB requirements.

1. “Data security is the top concern, initiative, and functional requirement for cloud security solutions,” with 87 percent of respondents indicating they are “very concerned” or “somewhat concerned” about storing sensitive data in the cloud, and another 82 percent indicating the same about data leaking through shadow IT. Anecdotally, we have seen the same, with more than 90 percent of our Active and Introspection customers implementing DLP.

From a requirements standpoint, this concern (and solution popularity) points to a need for not just cloud-based data loss prevention, but truly enterprise-grade cloud DLP. Many customers have felt burned by DLP initiatives in the past. Traditional DLP solutions have proven hard to implement, required armies to tune and manage, and still struggle with detection accuracy. What they expect from their next-generation, cloud-based DLP is to solve much of the problem they experienced in the past. They want all of the advanced DLP features such as thousands of language-independent data identifiers, support for custom keyword dictionaries, support for hundreds of file types, true file type detection, metadata extraction, proximity analysis, volume thresholds, international support including double-byte characters, document fingerprinting, content exact match, “and” and “or” rules, validation mechanisms such as Luhn check for credit cards, and more. They also expect to be able to use much of the cloud context (identifying the “who,” “what,” “when,” “where,” “on what device,” “with what type of content,” “in what app/app instance/app category,” “to or with whom,” “in what activity, such as ‘upload’ or ‘share,’” and the other contextual factors of any cloud transaction) to narrow down potential violations to a precise set of circumstances where a DLP violation is likely to occur or is harmful if it does. These are what create accurate detections and effective cloud DLP, and what our customers increasingly expect to address this concern.

2. “Compliance is a priority for governing the use of cloud applications,” with PCI DSS and HIPAA HiTECH as the most oft-cited regimens to comply with.

This concern carries with it critical requirements in our customer base. Many of our customers have stringent regimens to comply with because they are in regulated industries such as financial services, healthcare, energy, utilities, and retail. Even less regulated industries are concerned about privacy legislation, especially with the European Union ratifying the General Data Protection Regulation (GDPR). This comes into play within CASB in a few places: First, customers expect the enterprise-readiness rating of cloud apps to reflect compliance with key regulations. This is table-stakes and should be a baseline expectation. Second, they need predefined DLP templates (as well as easily-implementable custom ones) that help them comply with these regulations. Where the rubber hits the road here is that these templates need to be available for ANY app or category, not just  in one or two sanctioned apps. And finally, they require a robust incident management and reporting process to deal with violations once they occur. These should be available within CASB and via integrations with on-premises systems. These requirements go well beyond helping customers identify apps that violate regulations, and actually help them do what it takes to both comply and prove compliance.

3.  “Shadow IT and sanctioned IT are the visibility and control constructs of cloud security.”

This concern points to the requirement that CASBs should not just point out the existence of shadow IT, but actually help organizations control it. Most CASBs take the approach of discovering shadow IT, sanctioning a couple of apps, and blocking the rest. While in theory this sounds like a wonderful approach, in reality it doesn’t work. This is because most innovation today happens in the cloud, and as a result nearly all line of business apps (finance, accounting, HR, CRM, supply chain, software development, ERP, marketing, and more) are cloud-based. IT can’t possibly control all of them, nor would they want to. But they can’t block them either because they’re the way business gets done today. So they need to find a way to maintain some level of visibility and control even when they don’t administer the app. Even in the low-hanging fruit of Cloud Storage (file sync and share), IT can’t pick one and eschew the rest. What about the myriad external collaborators – customers, suppliers, and partners – that need to share presentations, requirements documents, contracts, statements of work, and other content with an organization’s employees. IT cannot block those apps. Rather, they should be able to granularly set policies that govern the usage of those apps (e.g., “You may download from any app (or any app that meets our minimum enterprise-readiness threshold), but you may only upload business content to our sanctioned app”).  A rapidly increasing number of our customers are taking this approach. Today’s prevailing customer requirement is not just discovering shadow IT, but governing its usage.

4. “The Cloud Access Security Broker market is maturing quickly, and experiencing growing pains.” The report goes on to state that CASBs are increasingly serving as an aggregation point for security services.

From a requirements standpoint, this is critical. Our customers are increasingly articulating their own CASB requirements (many of which we’ve aggregated and are happy to share if you reach out to us), and they are wide-ranging. They include shadow IT controls, cloud app ratings, advanced cloud DLP, multi-mode deployments, anti-malware and threat intelligence, and more. Nearly every inbound CASB request goes well beyond one use case and demands an aggregated set of cloud security services in a single platform.

5. “Multi-mode deployments of CASBs are required to enable visibility and control use cases.” When given the choice of implementation mode, respondents chose “all modes” over their “preferred mode” by a factor of more than 3x for every articulated use case.

CASB customers require a multi-mode architecture, even for their initial use cases. Today, more than three-quarters of our customers have deployed Netskope in at least two of our seven deployment options. They have found that they not only need to satisfy multiple use cases at once, but that they can gain leverage between each use case. For example, our customers learn a great deal from their DLP detection in their API-only (Introspection) deployment, and they use those to enforce DLP policies in unsanctioned app categories, leading to detection of vast amounts of data leakage via shadow IT. Multi-mode architecture is a critical requirement for today’s CASB.

The report is incredibly comprehensive and should be used as a key piece of research as you prepare for your CASB project. You can find it here.